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SYSTEM AND METHOD FOR PROVIDING 
VALUE-ADDED SERVICES (VAS) IN AN INTEGRATED 
TELECOMMUNICATIONS NETWORK USING SESSION INITIATION 

PROTOCOL (SIP) 



PRIORITY STATEMENT UNDER 35 U.S.C §119(e) & 37 C.F.R. §1.78 

This nonprovisional application claims priority based upon the following prior 
U.S. provisional patent application entitled: "System and Method for Providing Value- 
Added Services in IP Telephony," Ser. No. 60/140,013, filed June 18, 1999, in the 
names of: Roch Glitho, Christophe Gourraud, and Evelina Evloguieva. 

BACKGROUND OF THE INVENTION 

Technical Field of the Invention 

The present invention relates to integrated telecommunication systems and, 
more particularly, to a system and method for provisioning Intelligent Network (De- 
based Value-Added Services in an integrated telecommunications network which 
includes a packet-switched network (PSN) portion operable with Session Initiation 
Protocol. 

Description of Related Art 

Coupled with the phenomenal growth in popularity of the Internet, there has 
been a tremendous interest in using packet-switched network (PSN) infrastructures 
(e.g., those based on Internet Protocol (IP) addressing) as a replacement for, or as an 
adjunct to, the existing circuit-switched network (CSN) infrastructures used in today's 
telephony. From the network operators' perspective, the inherent traffic aggregation 
in packet-switched infrastructures allows for a reduction in the cost of transmission 
and the infrastructure cost per end-user. Ultimately, such cost reductions enable the 
network operators to pass on the concomitant cost savings to the end-users. 

Some of the market drivers that impel the existing Voice-over-IP (VoIP) 
technology are: improvements in the quality of IP telephony; the Internet phenomenon; 
emergence of standards; cost-effective price-points for advanced services via media- 
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rich call management, et cetera. One of the emerging standards in this area is the well- 
known Session Initiation Protocol (SEP), developed by the Internet Engineering Task 
Force (EETF) for multimedia communications over PSNs. Using SEP, devices such as 
personal computers can inter-operate seamlessly in a vast inter-network, sharing a 
5 mixture of audio, video, and data across all forms of PSNs which may interface with 

CSN portions. 

As is well-known in the telecommunications industry, services and service 
provisioning are the raison d'etre of a telecommunications network, including VoIP 
networks. Services are typically categorized into (i) "basic services" (i.e., services 

10 which allow basic call processes such as call establishment and termination) or (ii) 
"advanced services" which are also commonly referred to as Value-Added Services 
(VAS). Examples of advanced services include split charging, 800-services, credit 
card calls, call forwarding, hunt group, et cetera. It is also well-known that advanced 
services operate as factors for market differentiation and are crucial for network 

15 operators' (or service providers') success. 

Value-Added Services in SIP-based VoIP networks are known as "standard 
telephony services" whose architecture draws quite heavily on the Internet's "end-to- 
end" paradigm and focuses on service creation. While service provisioning schemes 
based on SEP's service architecture offer certain strengths (e.g., flexibility in role 

20 mapping for realizing services with end-to-end connectivity and having intelligence 
distributed to the "edges" of the network), there exist several disadvantages and 
drawbacks. For instance, in SIP, service logic is provided to be co-located with the 
SEP-based IP telephony entities. Accordingly, in current implementations, SEP-based 
networks do not have the capability to effectively access remote service logic, e.g., 

25 Intelligent Network (IN)-based logic, that is already deployed in the market and geared 

to provide an array of customer-validated VAS. Moreover, if the IN-based service 
logic were to be used today in the context of SEP, SEP-based entities would need to 
support IN protocols (i.e., IN Application Protocol (INAP) over Signaling System 7 
(SS7) or over EP) in order to remotely access the IN service node (e.g., Service Control 

30 Point or SCP) containing the service logic. 

Those skilled in the art should readily appreciate that a significant part of the 
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problem in providing remote service access capability to SIP-based entities stems from 
the fact that the two protocols, SEP and IN, follow different approaches and cannot be 
easily combined harmoniously. As is well-known, SIP is a lightweight, text-based 
protocol designed for Internet applications where space efficiency is of little concern. 

5 On the other hand, IN protocols are binary (i.e., coded in the Abstract Syntax Notation 
or ASN) and optimized for providing a large variety of V AS with parameters provided 
in rather complicated data structures. Using IN protocols to remotely access service 
logic in the context of SIP-based networks, accordingly, implies imposing additional 
functionality on IP telephony entities and introducing an extra category of 

1 0 "heavyweight" protocols in the network environment. 

Based on the foregoing, it should be apparent that there has arisen an acute 
need for a service provisioning solution which advantageously provides remote service 
access capability within a SEP-based telecommunications network. The present 
invention provides such a solution. 

15 

SUMMARY OF THE INVENTION 

In one aspect, the present invention is directed to a method of providing a 
Value-Added Service (VAS) in a telecommunications network operable with Session 
Initiation Protocol (SIP). The telecommunications network includes a SIPext SSP 

20 server, a trigger server, and a service node supporting VAS that is operable with 
Intelligent Network Application Protocol (INAP). Before processing a call 
(originating or terminating) between two users, which is effectuated by receiving a 
request message in the SIPext SSP server, the SIPext SSP server consults a user profile 
stored in the trigger server when a message for a user subscribed with a service 

25 provider arrives thereat. While processing the call, upon encountering an armed 
detection point for the subscribed service, a SEP register request is formulated by the 
SIPext SSP server based on the user profile obtained from the trigger server. The 
register request preferably includes at least one header field which contains 
information specifying an operation that the service node is to perform with respect 

30 to the VAS. The header field further includes call context data associated with the call 
initiated by the first user. 



o o 



WO 00/79756 PCT/SE00/01276 



-4- 

Subsequently, the register request is transmitted by the SIPext SSP server to 
the service node which launches the SLP based on the operation specified in the 
header field and the call context data associated therewith. The service node then 
formulates a SIP response message and transmits it to the SIPext SSP server, the 
5 response message including a header field and a return result obtained in response to 
the execution of the SLP by the service node. The SIPext SSP server executes an 
action responsive to the header field and the return result in the response message 
received from the service node, wherein the action corresponds to the provisioning of 
the VAS. In an exemplary embodiment, the return result comprises a destination 

10 routing number for a call forwarding service subscribed by the second user. 

In another aspect, the present invention is directed to an integrated 
telecommunications network for providing a Value-Added Service (VAS). The 
integrated telecommunications network comprises a SIPext SSP server which includes 
a proxy server and a service switching part. In one exemplary embodiment, the proxy 

1 5 server and the service switching part are addressable by two separate Internet Protocol 
(IP) addresses. The proxy server is provided for receiving a call initiation message 
from a first user with respect to a second user. The service switching part is included 
for determining if the second user has a subscription for the VAS. A trigger server 
containing user profiles associated with the VAS is also included in the 

20 telecommunications network. Also, the service switching part is provided with the 
capability for formulating a register request based on user profile information for the 
second user retrieved from the trigger server, wherein the register request includes a 
header field containing an operation associated with the VAS. The 
telecommunications network further includes a service node which contains an 

25 Intelligent Network Application Protocol (ENAP)-compliant Service Logic Program 
(SLP) associated with the VAS and a SIPext SSP interface server for receiving and 
interpreting the register request from the service switching part. Preferably, the service 
node executes the SLP based on the contents of the header field in the register request 
received from the service switching part. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention may be had by 
reference to the following Detailed Description when taken in conjunction with the 
accompanying drawings wherein: 
5 FIG. 1 (Prior Art) depicts a simplified message flow diagram for an exemplary 

call setup scenario in a conventional SIP-based network; 

FIG. 2 depicts a functional block diagram of the architecture of an exemplary 
integrated communications network wherein IN-based service logic (i.e., SCP) is 
advantageously accessed from a SIP-based network portion by utilizing Extended SIP 
1 0 (ESIP or SIPExt) structures provided in accordance with the teachings of the present 
invention; 

FIG. 3 A depicts a functional message flow diagram which illustrates the basic 
operation of an integrated telecommunications network provided in accordance with 
the teachings of the present invention; 
1 5 FIGS . 3B and 3 C depict a flow chart illustrating the steps involved in the basic 

operation of Extended SIP messaging used in an integrated telecommunications 
network; 

FIGS. 4A and 4B depict exemplary INAP tree data structures for providing 
parametric data; 

20 FIG. 5 depicts a functional message flow diagram illustrating the functionality 

of a SIPExt SCP node as a client; 

FIG. 6 depicts a functional message flow diagram illustrating the functionality 

of a SIPExt SSP component as a client, wherein an Extended SIP REGISTER message 

is forwarded to a SIPExt SCP node as result of event detection; 
25 FIG. 7 depicts a functional message flow diagram illustrating the functionality 

of a SIPExt SSP component as a client, with its request to a SIPExt SCP node being 

unsuccessful; 

FIGS. 8A - 8D depict various message flow diagrams for providing an 
exemplary Value-Added Service in an integrated communications network in 
30 accordance with the teachings of the present invention; and 

FIG. 9A - 9E depict various message flow diagrams for providing another 
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exemplary VAS in an integrated communications network in accordance with the 
teachings of the present invention. 



DETAILED DESCRIPTION OF EMBODIMENTS 

5 In the drawings, like or similar elements are designated with identical reference 

numerals throughout the several views, and the various elements depicted are not 
necessarily drawn to scale. Because the teachings of the present invention are 
particularly exemplified in the context of SEP-based messaging, a brief description 
thereof is set forth hereinbelow. 

10 SIP is an application-layer control protocol that can establish, modify, and 

terminate multimedia sessions or calls with one or more participants. These 
multimedia sessions include, for example, multimedia conferences, multimedia 
distribution, distance learning, Internet Telephony, and similar applications. Members 
in a session, typically denoted as users, can communicate via multicast or via a mesh 

15 of unicast relations, or a combination of both. 

SIP can invite both persons and "robots," such as a media storage service to a 
session. Typically, SEP invitations used to create sessions carry session descriptions 
which allow participants to agree on a set of compatible media types. Also, SIP can 
be used to initiate sessions as well as invite members to sessions that have been 

20 advertised and established by other means. For example, SEP sessions can be 
advertised using multicast protocols such as Service Advertising Protocol (SAP), 
electronic mail, news groups, World-Wide Web (WWW) pages, directory access 
protocols such as Lightweight Directory Access Protocol (LDAP), among others. 

SEP makes minimal assumptions about the underlying transport and network- 

25 layer protocols. The lower layers can provide either a packet or a byte-stream service, 
with reliable or unreliable service. In the Internet context, SEP is able to use both User 
Datagram Protocol (UDP) and Transport Control Protocol (TCP) as transport 
protocols, among others. 

In a SIP-based telephony network, users place calls via entities known as user 

30 agent clients (UACs) and receive calls via user agent servers (UASs). Accordingly, 
a SEP "user" is identified by a particular combination of a UAC and its associated 
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UAS. Also, usually, there may be intermediate servers between a calling party UAC 
and the called party UAS. Some of the relevant SEP entities are briefly defined 
hereinbelow: 

- User Agent Client: Also known as a calling user agent. It is an 
5 application which initiates a SIP request. 

- User Agent Server: Also known as a called user agent. It is an 
application which contacts the end-user when a SIP request is received. 
Also, it returns a response on behalf of the user since the user may 
select to accept, reject, or redirect the request. 

10 - Proxy or Proxy Server: It is an intermediary application which acts as 

a client as well as a server for the purpose of making requests on behalf 
of other clients. As a server, it receives SIP requests from other SIP 
entities. It either services the requests internally or acts as a client 
towards other servers in order to get the requests serviced. A proxy 

15 interprets and, if necessary, rewrites a request message before 

forwarding it. 

- Redirect Server: It is an application which accepts a SIP request, maps 
the address into one or more new addresses and returns these addresses 
to the client. Unlike a proxy server, it does not initiate its own SIP 

20 request. Also, unlike a UAS, it does not accept calls. 

- Registrar: A registrar is a server that accepts REGISTER requests. It 
may typically be co-located with a proxy or redirect server. 
Essentially, it operates as an application which allows end-users to 
register their current location. 

25 The basic protocol functionality and its operation is summarized in the 

following. Calling parties (also referred to as "callers") and called parties (also 
referred to as "callees") are identified by SIP addresses which point to "objects" on a 
network. The objects are "users at hosts," having appropriate SIP Universal Resource 
Locators (URLs) as addresses. The SIP URL typically takes a form similar to a mailto 

30 or telnet URL, i.e., user@host. The user part is generally provided as a user name or 
a telephone number. The host part typically comprises a domain name having a 
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Domain Name System (DNS) Sewer Name, CNAME, or a numenc network address, 
among others. 

The client-server approach of the SEP methodology employs a text-based 
messaging scheme. A SIP message is either a request from a client to a sewer, or a 
5 response from a server to a client. Both types of messages typically comprise a start- 
line, one or more header fields (also known as "headers"), an empty-line (i.e., a line 
with no text before a carriage-return line-feed (CRLF)) indicating the end of the header 
fields, and an optional message body. 

A SEP Request message format is usually as follows: 
10 Request = Request-Line 

* (general header 
j request-header 

| entity-header ) 
CRLF 

15 [ message-body ] 

After receiving and interpreting a Request message, a recipient (or sender) 
responds with a SEP Response message having a format shown below: 
Response = Status-Line 

* (general header 

20 ! response-header 

| entity-header ) 
CRLF 

[ message-body ] 

The Request-Line of a SEP Request message begins with a method token which 
25 allows a particular procedure or action from the requesting entity or the recipient(s) (or 
sender(s)) of the Request message. The following methods are currently implemented 
in SEP: 

INVITE: used to request connection establishment. 

ACK: allows clients to confirm that they have received a final response to an 
30 INVITE Request. 

BYE: used to request connection termination. 
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OPTIONS: used to query servers with respect to their capabilities. 
REGISTER: conveys information about user location. 
CANCEL: cancels pending Requests. 

The header fields in SIP messages are provided for characterizing or further 
5 defining a particular end-to-end or hop-by-hop message and the participating entities. 
General header fields apply to both Request and Response messages. The "entity- 

I; 

header" fields define meta-information about the message-body or, if no body is 
present, about the resource identified by the message. The "Request-header" fields 
allow the client (i.e., the requesting entity) to pass additional information about the 

1 0 Request, and about the client itself, to the server. These fields act as Request message 
modifiers. The "Response-header" fields allow the server to pass additional 
information about the response which cannot be placed in the Status-Line. These 
header fields include information about the server and about further access to the 
resource or resources identified in the Request message. 

15 Depending upon the method token used in the message, the header fields are 

defined as "required" (i.e., mandatory), "optional," and "not applicable." Some of the 
mandatory header fields, regardless of the method token, are: "Call-ID", "Cseq" 
(Command Sequence), "From", "To", and "Via", among others. An example of an 
optional header is the "Require" header field used by clients to inform U ASs about the 

20 options that the client expects the server to support in order to properly process its 
Request. Whereas end-to-end headers are transmitted unmodified across all proxies, 
hop-by-hop headers may sometimes be modified by the proxies encountered in the 
hops. 

Header fields follow a generic format wherein each header field consists of a 
25 name followed by a colon (":") and the field value. Field names are typically case- 
insensitive, while their values maybe. A common form of the header fields is set forth 
below: 

message-header = field-name ":" [field- value] CRLF 
field-name = token 

30 field-value = * (field-content | Leading White Space) 

field-content = < the OCTETS making up the field-value and others > 
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A typical SIP transaction in a conventional IP network maybe exemplified by 
referring to FIG. 1, wherein a simplified message flow diagram for a call setup 
scenario is depicted. A proxy server 1 04 is co-located with a SEP registrar for allowing 
users to register therewith. User-1 1 02 (shown as a combination of a U AC and UAS) 
5 and User-2 1 06 (also provided as a combination of a UAC and UAS) are provided as 
the participants in this call setup scenario. It is further assumed in this example that 
User-1 102 is the calling party and User-2 106, the called party with the SEP URL 
user2@location-A t has moved to a new location user2@location-B. 

First, the UAC of User-2 106 registers its new location with the registrar co- 

10 located with the proxy server 104 by sending a REGISTER message 108. The SEP 
URL associated with of the new location is provided as part of the REGISTER 
message 108. Thereafter, when the UAC of User-1 102 sends an INVITE Request 
message 1 10 with user2@location-A as the destination address, the proxy server 104 
obtains the new address of User-2 106 from the registrar and sends an INVITE 

15 Request message 1 12 to User-2 on behalf of the calling party. In response, User-2 
sends an INVITE Response 1 1 4 which is forwarded by the proxy server 1 04 to User- 1 . 
It should be understood by those of ordinary skill in the art that other SEP messages 
such as, for example, the ACK messages, are not shown in this simplified message 
flow diagram. After receiving the INVITE Response message 1 1 6 from the proxy 1 04 

20 by the calling party, a Call Session 1 1 8 may then be established between User- 1 and 
User-2. 

Whereas the brief overview of SEP functionality and messaging operation 
provided hereinabove is believed to set forth a proper and adequate framework for the 
present invention, additional details may be found in the Internet Draft ietf-mmusic- 
25 sip-1 l.txt promulgated by the EETF and located at < http://\\<\v\\\-ietf.orv/iniernei- 
drafTs/draft-ietf-mmusic-siv-1 1> . This Internet Draft is incorporated by reference 
herein. 

Referring now to FIG. 2, depicted therein is a functional block diagram of the 
architecture of an exemplary integrated telecommunications network 200 wherein EN- 
30 based service logic is advantageously accessed from a SEP-based network portion. In 
accordance with the teachings of the present invention, SIP messaging formats are 
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extended so that SIP servers are provided with the capability to access the service logic 
stored in IN-based nodes (i.e., SCPs). Essentially, the SIP servers and SCP nodes are 
provided with service switching interfaces that interact and operate based on the 
extended SIP messaging, referred to as SIPext messaging hereinafter. Further, 
according to the extended SIP messaging scheme set forth herein, clients are expected 
to include an appropriate extension name in a Require header field when using the 
extensions of the present invention. 

The integrated communications network includes one or more users as 
combinations of pure SIP UACs and UASs. For example, two users, User A 202 A and 
User A 202B, are illustrated in the architecture shown in FIG. 2. A trigger server 206 
is provided for storing user profiles which contain, for example, lists of services for 
which users have subscriptions. 

One or more SIPext Service Switching Point nodes (SSPs) (for example, 
SIPext SSP node 204 operating as a switching node) are provided within the integrated 
communications network 200 for interacting with the various users and trigger server 
or servers of the SIP network portion. Further, the SIPext SSP 204 is provided with 
the capability to interact with an IN service node in a manner described in greater 
detail hereinbelow. 

In a presently preferred exemplary embodiment of the present invention, the 
SIPext SSP node 204 is comprised of two functional parts: a SIP server part 208 and 
a SIPext Service Switching part 2 1 0, each of which may be separately IP-addressable. 
The SIP server part 208 preferably operates as a pure SIP proxy server and provides 
the basic call services, that is, call setup and call termination. The SIPext Service 
Switching part 210 is provided as a SIPext server that operates as an IN SSP. The 
SIPext Service Switching part 210 preferably provides the following functionality: 



trigger detection; 

sending SIPext Request messages to an IN SCP for triggering 
appropriate Service Logic Program (SLP) execution; 
sending Requests and Responses for interaction with an already 
running SLP; 

receiving and interpreting SIPext Requests or Responses from an SCP; 
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and 

- transferring control to the SIP server part 208 for performing related 
SIP signaling. 

In accordance with the teachings of the present invention, an IN SCP is also 
5 provided with the functionality of a SIPext server 2 1 4 (preferably operating as a SEPext 
SSP interface server), thereby becoming a SEPext SCP node 212. The SIPext server 
214 of the SIPext SCP node 212 preferably performs the following: 

- providing for the communication with the SIPext SSP 204; 

- interpreting SIPext messages; 

10 - transferring control to one or more IN SLPs (e.g., SLP 216); and 

formulating appropriate SEPext messages. 
As mentioned in the foregoing, the SIPext SSP node 204 may preferably be 
provided with two IP-addresses, EP ADDR1 209 and IP ADDR2 211. It should be 
readily appreciated by one of ordinary skill in the art that IP ADDR1 209 corresponds 

15 to the pure SEP part, i.e., the SIP server 208, responsible for the call setup between the 
end parties. The other IP-address, IP ADDR2 211, corresponds to the Service 
Switching part 210 of the SIPext SSP 204. In the examples described in greater detail 
hereinbelow, these two IP addresses are denoted as "provider.com" and 
"ssp.provider.com", respectively. 

20 It should be realized that having two separate addresses makes it possible to 

distinguish between SEPext-SCP messages and those associated with the pure SEP 
network nodes. For example, a Response message sent to the pure SIP part (i.e., SIP 
server 208) of the SIPext SSP node 204 means that the message needs to be processed 
as part a basic call service. On the other hand, if a Response message is sent to the 

25 Service Switching part 210 of the SIPext SSP 204 using the EP ADDR2 211, that 
message is to be interpreted and processed according to SIPext rules. 

Those skilled in the art should understand that it is also possible for the SIPext 
SSP node 204 to have only one IP address. However, this condition would require that 
the SIPext messages be distinguished from the pure SEP messages. It should be 

30 apparent that the Require: header field may be used to specify the type of messaging 
and, for example, by providing Require: inap.sip in the message header, the SIPext 
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SSP 204 may be notified that the message is a SIPext message to be processed by the 
SIPext Service Switching functionality part 210. Clearly, this approach requires that 
all messages directed to the IP address of the SIPext SSP node 204 be first classified 
by their Require: header. 

5 FIG. 3 A depicts a functional message flow diagram which illustrates the basic 

operation of an integrated communications network provided in accordance with the 
teachings of the present invention. User A 202A places a call to User B 202B using 
a pure SIP message, INVITE 302. When the message is received in the SIPext SSP 
node 204, the SIPext SSP node queries or consults with the trigger server 206 via a 

1 0 suitable IP message 303 to obtain user profile information pertaining to User B 202B. 
While processing a call, upon encountering an armed detection point for the 
subscribed service, the SIPext SSP node 204 formulates a suitable SIPext request 
message 304 and forwards it to the service node, SIPext SCP 212. As will be 
explained in greater detail hereinbelow, the SIPext message 304 is a SIP-compatible 

15 message with additional header/field information specifying the service trigger to be 
handled the service node 212. Preferably, the SIPext request messages take the form 
of SIP REGISTER messages with INAP-compliant service-related information in the 
additional headers and fields. Analogously, SIPext responses assume the form of 
suitable SIP messages with additional headers and fields also. 

20 Continuing to refer to FIG. 3 A, upon receiving the SIPext REGISTER message 

304, the service node 212 performs the service specified therein and provides a SIPext 
OK response 306 to the SIPext SSP node 204 if the SLP is successfully executed. 
Responsive to the SIPext OK response, the SIPext SSP node analyzes its header fields 
which specify what the SIP Server part of the SIPext SSP node 204 should do. 

25 Accordingly, the SIP Server routes the call using a pure SIP message 308, based on the 
results obtained from the SLP in the service node 212. 

In the exemplary SIPext operation described above, it is possible that the SLP 
may not be successfully executed for some reason and, consequently, an error message 
may be generated by the service node 212. Upon receiving the error message, the 

30 SIPext SSP node 204 may reformulate the REGISTER message and forward it to the 
service node again, return an error response to User A 202A, or perform some other 
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action. 

FIGS. 3B and 3C depict a flow chart of the steps involved in the basic SEPext 
operation described hereinabove. Upon receiving a message in the SIPext SSP node 
(step 322), the SIPext SSP node retrieves the user profile of the recipient (or sender) 
5 (step 324). Based on the user profile information obtained from the trigger server, the 
SIPext SSP node may behave as a standard SIP server or formulate a SIPext request 
message (step 328) and transmits it to a service node with an appropriate SIPext 
interface, wherein the service node is capable of executing SLPs associated with VAS 
(step 330). 

10 Upon receiving the SIPext request message from the SIPext SSP node, the 

service node interprets the information provided in the request message to construct 
a suitable INAP instruction (step 332) that launches the execution of one or several 
SLPs (step 334). Thereafter, the service node transmits the results (including error 
messages, if any) obtained from the SLP operation (i.e., successful execution, non- 
15 execution, or partial execution, etc.) to the SIPext SSP node in a SIPext response 
message (step 336). Subsequently, the SIPext SSP node takes an appropriate action 
(call routing, error reporting, reformulating the SIPext request message, etc.) on the 
basis of the result information received from the service node (step 338). Thereafter, 
the process flow associated with the basic SIPext operation ceases (step 340). 
20 The structure of the SIPext header fields for SIPext messaging in accordance 

with the teachings of the present invention is now set forth immediately hereinbelow. 
Those skilled in the art should appreciate that the extension of SEP messages as 
provided herein advantageously allows the use of SEP as a protocol for communication 
between SIP entities and EN-based SCPs. Further, the SIPext messaging provides a 
25 useful Internet implementation of ENAP such that the benefits of integrating PSNs and 
CSNs in the context of telecommunications may be expeditiously realized. 

In a presently preferred exemplary embodiment of the present invention, the 
following four header fields are defined: 
- Operation: 

30 The Operation: header field advises the recipient (or sender) entity to perform 

the operation specified in the content of the header. In addition to the name of the 
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operation, the header may preferably contain the parameters of the operation, if any. 
Further, the operation and the parameters' name, type, and value correspond to those 
defined in INAP. 

The format of the Operation header field in the Backus-Naur form (i.e., BNF 
5 notation) is given below: 

Operation = "Operation" ":" name-operation [operation-param] 
name-operation = 1* alpha 

operation-param = *("parameter" ":" parameter- value ";") 

parameter = *(/( 1 * alpha)) 
10 parameter-value = *DIGIT| * CHAR [boolean | * OCTET 

Some of the examples of this header field and the translation of INAP data 
structures (used for the header arguments) in accordance with the teachings of the 
present invention are set forth later on hereinbelow. 

- Result-op: 

15 The Result-op: header field carries the result(s) of the successful execution of 

an operation. This header is preferably present in the response message only, if the 
operation requires that the result(s) of the operation be sent back to the entity that 
invoked the operation (i.e., SIPext SSP node or SIPext SCP, for example). 

The format of the Result-op: header in the usual BNF notation is given below: 
20 Result-op = "Result-op" ":" [result-arguments] 

result-arguments = *("argument" ":" argument-value **;") 
argument = *(/l *alpha)) 

argument-value = *DIGIT|*CHAR| boolean |*OCTET 

Example: Result-op: /digitsResponse: 456; 
25 This example shows the result returned after the execution of 

Receivedlnformation operation and represents an instance of the 
ReceivedlnformationArg parameter. 

- Error-op: 

The Error-op: header field is used to convey information regarding an 
30 unsuccessful operation and the reason or reasons therefor. 
The BNF format of the Error-op: header is: 
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Error-op = "Error-op" ":" error-name ";" [*(error-parameters [":" parameter- 
value)] ";"] 
error-name = 1 *alpha 
error-parameters = *(1 *alpha) 
5 parameter-value = * DIGIT | *(1 *alpha) 

Some of the examples of the Error-op: header field usage are below: 

Error-op: CancelFailed; problem:unknownOperation; operation:654 
Error-op: MissingParameter; 
- Oseq: 

10 In a presently preferred exemplary embodiment, the SIPext node that generates 

a SIPext REGISTER request adds the Oseq: header field to every request. The 
contents of this field represent the order of the operation requests sent for a specific 
Call-Id such that the operations are preferably executed in the same order. The Oseq: 
sequence number is also used to match the responses to the requests. 
15 The format of the Oseq: header field is as follows: 

Oseq = "Oseq" 1*DIGIT "REGISTER" 
Example: Oseq: 3 REGISTER 

Based on the foregoing discussion, it should be apparent that the contents of 
the Operation: header field provided in accordance with the teachings of the present 

20 invention essentially control the SIPext functionality between two SIPext entities such 
as, for example, the SIPext SSP node 204 and the SIPext SCP 212 depicted in FIG. 
3A. As briefly alluded to hereinabove, the arguments in the Operation: header field 
dictate the context of the operation and preferably correspond to the parametric 
information necessary for executing INAP-compatible operations by the receiving 

25 entity. 

The INAP parametric information is optimized for supporting a large variety 
of VAS and, consequently, is specified in the Abstract Syntax Notation- 1 (ASN.l 
format) which is well suited for a "heavyweight" protocol (such as INAP) requiring 
rather complicated data structures like nested formats, uni- and multi-dimensional 
30 trees, etc. for representing numerous optional elements. However, those skilled in the 
art should appreciate that the text-based parameter-value structure of the Internet 
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application protocols, including SIP, are optimal where the parameters are notheavily 
structured and values are typically provided as simple lists. Accordingly, the present 
invention advantageously provides a solution for representing INAP-compatible 
parametric information in a linear format that is highly efficient for a "lightweight" 
5 Internet application protocol such as SIP in the form of SEPext messaging. 

Referring now to FIGS. 4A and 4B, depicted therein are two exemplary 
operation arguments that illustrate the tree data structures of INAP. In FIG. 4A, 
InitialDp operation argument 402 represents a uni-dimensional tree data structure. The 
following parameters are specified: serciceKey 404; dialedDigits 406; triggerType 

10 408; and miscCalllnfo 410 which is comprised of messageType 412 and 
dpAssignment 414. 

A multi-dimensional tree data structure is exemplified by 
CalllnformationReportArg 416 as illustrated in FIG. 4B. It can be seen that at each 
level in the data hierarchy, parameters have multiple paths, i.e., multiple origins in 

15 prior levels. A Requestedlnformation List 418 is comprised of multiple 
requestedlnformationValue elements 422 and 426, and multiple 
requestedlnformationType elements 420 and 424. 

Regardless of the dimensionality of the tree data structure, the present 
invention provides two mechanisms for linearly describing the argument data. In one 

20 exemplary embodiment, the basic data types (i.e., the leaves in the tree) are identified 
with the full path of data types that are above them in the hierarchy of the argument 
data structure. This path, accordingly, explicitly describes their location in the 
argument data structure tree. The receiving entity is provided with the knowledge 
regarding the corresponding argument data structure and the data types it is made of. 

25 

The InitialDp operation argument 402 is thus represented in a linear format as 
follows: 

/serviceKey:40, /dialedDigits:8876hjgda, /triggerType: oAnswer, 
/miscCallInfo/messageType:request, 
30 /miscCallInfo/dpAssignment:individualLine. 

The CalllnformationReportArg 416 may be described by the sequence: 
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/requestedln formation 

/requestedInformationList/requestedInformationValue:457, 

/requestedlnfoiroationList/requestedlnformationTypexallElapsedTime, 
/requestedInformationList/requestedlnforrnationValue:20, 
5 /correlationldil 11. 

In a second exemplary embodiment, each basic data type is identified with one 
parameter name. In the example of the InitialDp operation argument 402, the 
parameters can be described with the following names: 

/serviceKey:40, /dialedDigits:8876hjgda, /triggerType: oAnswer, 
1 0 /messageType:request, /dpAssignment:individualLine. 

In the example of the CalUnformationReportArg 4 1 6, the following sequence specifies 
the parametric information: 

/requestedlnformationTypexallStopTime, /requestedInformationValue:457, 

/requestedInformationType:callElapsedTime,/requestedInformationValue:20, 
15 /correlationId:l 1 1. 

In the second approach, the entity interpreting the operation is required to 
match the parameter name with its location (field) in the linear data structure storing 
the data, in addition to possessing the knowledge regarding the argument data structure 
and its building data types. 

20 Using either of the approaches set forth above for "linearizing" the INAP 

parametric information, it is possible to efficiently pack the VAS-related operations 
within the extended header fields of the SIPext messages in accordance with the 
teachings of the present invention. As set forth in the basic SIPext operation described 
with reference to FIGS. 3 A - 3C hereinabove, the functionality of the SIPext SSP node 

25 (acting as a client) typically includes formulating suitable SIPext REGISTER 
messages with appropriate extended header fields for executing IN-based SLPs. The 
receiving SIPext SCP node, accordingly, operates as a server towards the requesting 
SIPext SSP node. 

The functionality of a SIPext SCP node as a server may now be described in 
30 greater detail, taking particular reference to the extended header field information set 
forth above. Upon receiving a SIPext REGISTER request, the SIPext SCP node 
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checks whether the request comes from a SIPext SSP node by examining the topmost 
Via: header field. Using the Oseq: sequence number field, it determines whether the 
request needs to be processed next. The request maybe postponed if there are other 
requests with smaller Oseq: numbers either in process queue or have not been received 
5 yet. Accordingly, the SIPext SCP node maintains a counter or other suitable 
mechanism for monitoring the number of the last request processed for every Call-Id. 

Thereafter, the SIPext SCP node searches for Operation: header fields in the 
request. While all other headers (e.g., pure SEP headers which are not service related) 

10 and their contents remain unprocessed, the Operation: headers are parsed and, 
depending on the name or names of the operation(s), the corresponding INAP 
operation is performed using the linearized parametric data. For example, an SLP may 
be launched by the SIPext SCP node using such parametric data. 

If the operation is executed successfully, an OK response is generated. The 

1 5 OK response may contain another Operation: header field or a Result-op: header field. 
Pure SIP headers not related to service are simply copied in the OK response. On the 
other hand, if the operation is not executed successfully, an INAP error message is 
generated which is translated by the SIPext SCP node into a SIP error response. An 
Error-op: header is included in the response specifying the INAP error and parameters 

20 associated therewith. The following table, Table I, gives examples of INAP errors and 
the corresponding SIP error responses used for transporting them to the SIPext SSP 
node. 

Table I 

25 



INAP ERRORS 


SIP Error 
Responses 


MissingParameter 


400 Bad Request 


ParameterOutOfRange 


400 


SystemFailure 


500 Server Internal 
Error 
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N/f i^inpCiiQtnmprR prnrH 


son 


TaskRefused 


400 


UnexpectedComponentSequence 


400 


UnexptectDataValue 


400 


UnexpectedParameter 


400 


RequestedlnfoError 


400 



In some instances, the SIPext SCP node may operate as a client by requesting 
the SIPext SSP node to execute an operation. Referring now to FIG. 5, depicted 

1 0 therein is a functional message flow diagram illustrating the functionality of a SIPext 
SCP node as a client. The SIPext SCP node 212 transmits a REGISTER message 502 
to the SIPext SSP node 204 specifying the operation and its parameters in the 
Operation: header field. Generally, a REGISTER request sent by the SIPext SCP node 
212 requires the execution of operations that are not related to the call setup and, 

15 accordingly, the header fields carry less information than the headers in the 
REGISTER messages transmitted by the SIPext SSP node as a client. Also, the 
requests sent by the SIPext SCP node 212 are used in general to instruct the SIPext 
SSP node 204 (which acts as a server) to perform some call monitoring and event 
notification actions. 

20 After sending the REGISTER request 502, the SIPext SCP node 2 1 2 waits for 

a response message (e.g., OK response 504) from the SIPext SSP node 204. Once the 
response message is received, it is processed by the SIPext SCP node 2 1 2 to parse the 
Result-op: or Error-op: headers. 

The functionality the SIPext SSP node is now described in greater detail, with 

25 particular reference to the header field information provided hereinabove. As shown 
in FIG. 2, the SIPext SSP node 204 is comprised of the SIP server 208 (using pure SIP 
messaging) which performs the basic call setup and termination, and the Extended SIP 
(ESIP) Service Switching (SS) part or module 210 which is responsible for the 
signaling communication with the SIPext SCP node 212. In the context of the present 

30 patent application, accordingly, the functionality of the ESEP SS module 210 of the 
SIPext SSP node is focused in particular when the functionality of the SIPext SSP 
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node is addressed herein. 

In general, the SIPext SSP node (and its ESIP SS module 210) functions as a 
client towards the SIPext SCP node, as explained above with respect to the basic 
SIPext operation depicted in FIGS. 3A - 3C. The SS module sends requests to the 
5 SIPext SCP node in two situations: (i) when a trigger for a service is detected, or (ii) 
an event that needs to be reported to the SIPext SCP node. In a presently preferred 
exemplary embodiment of the present invention, the ESIP SS module 210 monitors 
all the INVITE messages sent to the pure SIP proxy server 208 of the SIPext SSP node 
204 (shown in FIG. 2) in order to be able to detect service-based triggers. In the 
1 0 exemplary embodiment shown in FIG. 3 A, the SIP proxy server 208 is identified with 
the IP address provider.com and the INVITE messages sent to this IP address are 
accordingly monitored by the ESIP SS module 210. If the recipient (or sender) of an 
INVITE message (i.e., User B 202B in FIG. 2) has a subscription for a VAS, the ESIP 
SS module 210 formulates the REGISTER request for the SIPext operation as follows: 
15 - Copies all the headers of the INVITE request so that the ESIP SS 

module may operate in a "stateless" mode (i.e., the SS module does not 
have to memorize the call state when the REGISTER request is sent to 
the SIPext SCP node). 

- Adds a Via: header field containing the address of the ESIP SS 
20 module. 

- Adds a Oseq: header containing the sequence number of the 
REGISTER request. This sequence number is used by the ESIP SS 
module to match the responses from the SIPext SCP node with its 
REGISTER requests. It is also used by the SIPext SCP node to 

25 execute the requested operations in a sequential order. 

- Adds one or more Operation: headers which specify the operation(s) 
to be executed by the SIPext SCP node, including the parametric 
information therefor that is linearized as described above. 

FIG. 6 depicts a functional message flow diagram illustrating the situation 
30 when a REGISTER request 602 is sent as a result of event detection. As can be 
appreciated by those skilled in the art, there may be some services which require that 
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the ESEP SS module report to the SIPext SCP node the occurrence of some specific 
event. Accordingly, the ESIP SS module formulates the REGISTER request 602 with 
the header fields as follows: 

- To:, From:, Call-Id:, Cseq: headers are included for carrying the 
5 contents of a call context. In most cases, the contents of these headers 

are not used for the execution of the requested operation because, 
generally, all the call context data needed is present in the Operation: 
header. 

- Oseq: header is used for sequencing the requests as explained above. 
10 - Via: header is used for specifying that the request is generated by the 

ESIP SS module of the SIPext SSP node 204. For REGISTER 
requests that are generated due to event detection, typically there is 
only one Via: header. 

- Operation: header that specifies the operation to be executed and its 
15 parameters. 

In response to the REGISTER request 602 requesting an operation to be 
performed by the SIPext SCP node 2 1 2, an OK message 604 may be transmitted back 
to the ESIP SS module of the SIPext SSP node 204 if the request 602 is successfully 
processed by the node 212. The OK response 604 preferably contains the SIPext 

20 Oseq: header and Operation: header, in addition to the following pure SIP headers: 
To:, From:, Call-Id:, and Via: . If the Operation: header is present, the ESEP SS module 
is required to perform the operation specified therein. For example, if the Operation: 
header indicates that the call has to be routed to a call forwarding number (i.e., the C- 
number), the ESIP SS module formulates the corresponding SEP request and transfers 

25 control to the pure SIP proxy server of the SIPext SSP node 204. 

FIG. 7 depicts a functional message flow diagram which illustrates the scenario 
wherein a SIPext REGISTER request (e.g., REGISTER request 702) is not 
successfully processed by the SIPext SCP node 212. A Bad Request message 704 is 
generated as a response, which preferably contains an Error-op: SIPext header for 

30 specifying the error type and parameters (if any). 

Depending on the contents of the Error-op: header and related parametric 
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information, the ESIP SS module of the SIPext SSP node 204 may take different 
actions. For example, it may retransmit the REGISTER request 602 immediately or 
after a predetermined time set forth in the Error-op: header field. Or, it may formulate 
a SEP message and transfer it to the SIP proxy server so that the caller is notified of a 
5 suitable response. 

Referring now to FIGS. 8 A - 8D, depicted therein are several functional 
message flow diagrams which illustrate an exemplary VAS implementation using the 
SIPext protocol of the present invention. More specifically, the provisioning of a 
freephone / call forwarding service in accordance with the teachings of the present 

1 0 invention is illustrated. First, an exemplary service implementation using ENfAP is set 
forth in order to provide a framework for service provisioning with SIPext protocol. 
Thereafter, service-specific messages using the protocol are illustrated by way of the 
functional message flow diagrams. 

Those skilled in the art should appreciate that depending on network-specific 

15 mechanisms for charging, there are several possible implementations of the call 
forwarding service in an IN-compliant environment. In the example provided herein, 
service charges are computed by the SCP. The exemplary INAP service 
implementation is described by the following sequence (where denotes an 
operation sent from SSP to SCP; denotes an operation sent from SCP to SSP): 

20 1 . InitialDp(ServiceKey = 0800, calledPartyNumber = 3456789) 

2. - Connect(destinationRoutingAddress = 6543210, 
correlationld =1111) 

RequestReportBCSMEvent(eventTypeBCSM = o_Answer, 
monitorMode=notifyAndContinue, eventTypeBCSM = o_Disconnect, 
25 monitorMode = notifyAndContinue, bcsmEventCorrelationld =1111) 

3. - EventReportBCSM(eventTypeBCSM = o_Answer, 
bcsmEventCorrelationld =1111) 

4. - EventReportBCSM(eventTypeBCSM = o_Disconnect, 
bcsmEventCorrelationld =1111) 

30 Referring now to FIG. 8A, User A 202A at a host (denoted as Ahost) places 

a call to User B with address 8003234@provider.com by way of an INVITE message 
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802. Upon receiving the INVITE message, the SIPext SSP node 204 consults a trigger 
server (not shown) and determines that User B has a subscription with respect to the 
freephone / call forwarding service. Thereafter, a SIPext REGISTER message 804 
containing two SIPext headers is formulated by the SIPext SSP node 204. The 
Operation: header specifies the SLP associated with the subscribed service that needs 
to be launched, and carries the call context data required for its execution. In the 
present example, this data is carried in the Called Party Number (B-number) 
parameter. Further, the Oseq: header is provided in accordance with the teachings of 
the present invention for specifying the operation sequence number. 

Upon receiving the SIPext REGISTER message 804, the SIPext SCP node 2 1 2 
analyzes the SIPext headers and launches the freephone SLP. After successfully 
executing the program, it generates an OK response 806 by copying all headers from 
the REGISTER message 804 except the Operation: headers. Two new Operation: 
headers are formulated by the SIPext SCP node instead, based on the results obtained 
from the SLP execution. The first one (Connect operation) specifies the destination 
number to which the call is to be routed or forwarded. The second operation header, 
Operation: RequestEventReport, instructs the SIPext SSP node to notify the SCP node 
for a Call Accepted (o_Answer) event or a Call Disconnected (o_Disconnected) event. 

After receiving the OK response 806, the SIPext SSP node 204 executes the 
operations specified therein. The Connect operation results in generating a pure SEP 
INVITE request 808 and transmitting it over the SIP network to the forward address 
4456(aiprovider.com. Responsive to the RequestEventReport operation, the SIPext 
SSP node 204 monitors the messages with the specific Call-Id number and in order to 
notify the SCP node 212 if an ACK or BYE message is generated for that Call-Id. 
Those skilled in the art should readily appreciate that the ACK message corresponds 
to the IN o_Answer (i.e., Call Accepted) event, and BYE corresponds to the 
o Disconnect (i.e., Call Disconnected) event. 

FIG. 8B depicts the flow of SIP messages exchanged when a user 202C (i.e., 
User C) at the host 4456 accepts the forwarded call. An OK message is transmitted 
back from User C to the pure SEP proxy server part of the SIPext SSP node 204 which 
then forwards it to the caller, i.e., User A 202A as an OK response 812. 
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FIG. 8C depicts the flow of messages when the SIPext SSP node 204 receives 
an ACK message 813 from the caller' s user agent in response to the OK response 812. 
The ACK message 813 is proxied by the SSP node 204 to User C 202C as the ACK 
response 8 1 4. Thereafter, a SIPext REGISTER request 8 1 5 is generated, including the 
5 BCSMEventReport operation for notifying the SIPext SCP node 212 the occurrence 
of the o_Answer event. In response, the SIPext SCP node 212 transmits an OK 
conformation 816 to the SSP node 204 and launches an SLP that bills the call on the 
4456 account. 

The SIPext SSP node 204 continues to monitor the signaling messages for the 
10 Call-Id associated with the caller (User A's Call-Id, e.g., 123@Ahost). When one of 
the parties decides to terminate the connection, its user agent issues a BYE request, 
which corresponds to an o_Disconnect event. FIG. 8D depicts the scenario where 
User A 202A issues the BYE request 818 to the SIPext SSP node 204. In response, 
a proxy BYE 824 is provided to the callee, i.e., User C 202C. Thereafter, a SIPext 
15 REGISTER request 820 containing the EventReportBCSM operation header is 
generated towards the SCP node 2 1 2. In response to the oJDisconnect event reported 
from the SIPext SSP node 204, the billing SLP in the SCP node completes the call 
billing process. An OK response 822 is transmitted back to the SSP node 204, 
preferably without any Operation: headers, as there is no need for additional actions 
20 from the SCP or SSP nodes. 

FIGS. 9 A - 9E depict functional message flow diagrams for a call distribution 
service provided in accordance with the teachings of the present invention. The 
following conditions are adopted in the exemplary scenario provided herein: 
1 . User B has a subscription for the call distribution Service. 
25 2. The maximum number of calls that User B is allowed to answer is 50 

calls per day. 

3. If the number of calls received is greater than 50, the calls are 

forwarded to the C-number 6543210. 
It should be readily apparent to those skilled in the art that the SIPext messages 
30 depicted in the FIGs. use the now-familiar header fields to instruct the SCP to launch 
appropriate SLPs associated with the service, depending on whether the call number 
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threshold is reached or not. For the sake of brevity, accordingly, only the salient 
features of this example are set forth hereinbelow. 

FIGS. 9A - 9D illustrate the condition where the subscriber/user encounters 
fewer than 50 calls. Calls are passed to User B after appropriate SIPext REGISTER 
5 and OK messages between the SIPext SSP node 204 and SIPext SCP node 212 which 
executes the call distribution SLP. Where there is a busy signal 924 from User B 
202B, as shown in FIG. 9C, the SIPext SSP node 204 proxies the same to the caller 
at Ahost (User A 202 A) and notifies the SCP node 2 1 2 via a REGISTER request 920. 
A Temporarily Unavailable response 926 (illustrated in FIG. 9D) is provided to User 

1 0 A 202A when User B's agent sends repeated Ringing messages 932 back to the SIPext 
SSP node 204 and a timer associated with the user response expires. Furthermore, the 
SSP node 204 notifies the occurrence of o_No Answer event to the SCP node 2 12 via 
a REGISTER request 928. 

FIG. 9E depicts the situation where more than 50 calls are encountered by the 

1 5 user. The call distribution SLP in the SIPext SCP node 212 provides a routing number 
using the Operation: Connect header in the OK response 938, which is subsequently 
used by the SEP proxy portion of the SIPext SSP node 204 to forward the calls to User 
C 202C at 6543210. 

Based on the foregoing, it should be appreciated that the present invention 

20 advantageously extends the capabilities of the existing SIP implementations to include 
access to the WIN/IN service logic base that is already installed and market-tested. 
Accordingly, the installed service base may continue to be re-used even as SIP-based 
VoIP network architectures evolve in the future. Those of ordinary skill in the art 
should realize that there exist tremendous incentives, economic as well as 

25 infrastructure-based, for network operators to re-use the expensive legacy SCP nodes 
as they migrate towards integrating the cellular infrastructures with IP-based PSNs. 
In addition, by appropriately linearizing the IN AP parametric information in the header 
fields of SIPext messages, the present invention solves the problem of having to 
support multiple protocols in a network in order to provide the capability to access 

30 remote service logic nodes. 

Further, it is believed that the operation and construction of the present 
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invention will be apparent from the foregoing Detailed Description. While the method 
and system shown and described have been characterized as being preferred, it should 
be readily understood that various changes and modifications could be made therein 
without departing from the scope of the present invention as set forth in the following 
5 claims. For example, although the teachings of the present invention have been 
exemplified with two particular services, it should be understood that other VAS may 
also be provisioned in accordance with the teachings of the present invention. That 
is, in addition to the call forwarding and call distribution services exemplified herein, 
the teachings hereof may be also applied in the context of the following services: toll 

1 0 free and credit card calling, cellular hunt, selective call restriction, click to fax, double 
phone / freephone, split charging, and multimedia applications such as tele-medicine, 
tele-education, video-on-demand, et cetera. 

Furthermore, while generic SIP user agents have been described in the 
exemplary embodiments of the present invention, any combination of SIP-compliant 

15 entities such as intelligent mobile stations operable with a variety of air interface 
standards, taken in conjunction with V AS-enabled Personal Digital Assistants, "smart" 
phones, personal computers, laptop computers, palmtop computers, Information 
Appliances, wireless transceiver wrist watches, pagers, et cetera, maybe provided for 
the purposes of the present invention. In addition, the innovative teachings contained 

20 herein may also be practiced in a VoIP network coupled to a PSTN, wherein the 
SEPext SSP node can trigger ESIP service requests to a service node having an 
appropriate SIPext server interface. Moreover, although the teachings of the present 
invention are exemplified by employing a SIP ext SSP node having two different IP 
addresses, it should be appreciated that the present invention is not limited thereto and 

25 the innovative teachings contained herein may be advantageously practiced in 
networks having a SIPext SSP node with a single DP address also, wherein a suitable 
mechanism for differentiating between pure SIP and SIPext messages is provided. 
Accordingly, it should be realized that these and other numerous variations, 
substitutions, additions, re-arrangements and modifications are contemplated to be 

30 within the ambit of the present invention whose scope is solely limited by the claims 
set forth below. 
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WHAT IS CLAIMED IS: 

1. A method of providing a Value-Added Service (VAS) in a 
telecommunications network operable with Session Initiation Protocol (SIP), the 
telecommunications network including a SIPext SSP server, a trigger server, and a 
service node having at least one Service Logic Program (SLP) associated with the 
VAS, wherein the SLP is operable with Intelligent Network Application Protocol 
(INAP), the method comprising the steps of: 

receiving a request message in the SIPext SSP server from a first user, 
the request message for initiating a call to a second user; 

upon receiving the request message, consulting the trigger server by the 
SIPext SSP server to obtain a user profile associated with at least one of the first and 
second users; 

formulating a SIP register request by the SIPext SSP server based on 
the user profile obtained from the trigger server, upon encountering an armed detection 
point during call processing, the register request including at least one header field, 
wherein the header field contains information specifying an operation that the service 
node is to perform, the header field further including call context data associated with 
the call initiated by the first user; 

transmitting the register request by the SIPext SSP server to the service 

node; 

upon receiving the register request, executing at least one SLP by the 
service node based on the operation specified in the header field and the call context 
data associated therewith; 

sending a SIP response message from the service node to the SIPext 
SSP server, the response message including a header field and a return result obtained 
in response to the execution of at least one SLP by the service node; and 

executing at least one action by the SIPext SSP server responsive to the 
header field and the return result in the response message received from the service 
node, the action being associated with the VAS. 
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2. The method of providing a VAS in a telecommunications network as 
set forth in claim 1, wherein the SIPext SSP server is addressable by two separate 
Internet Protocol (IP) addresses, a first IP address and a second EP address, and further 
wherein the request message is received in the SIPext SSP server from the first user 
using the first IP address. 

3. The method of providing a VAS in a telecommunications network as 
set forth in claim 2, wherein the register request is sent from the SIPext SSP server to 
the service node using the second IP address. 

4. The method of providing a VAS in a telecommunications network as 
set forth in claim 1 , wherein the step of formulating the register request comprises the 
step of transforming INAP-compliant data structures associated with the VAS into 
linearly sequenced parametric data forming a portion of the header field of the register 
request. 

5. The method of providing a VAS in a telecommunications network as 
set forth in claim 4, wherein the SEP-compliant response message from the service 
node comprises linearized INAP-compliant parametric information. 

6. The method of providing a VAS in a telecommunications network as 
set forth in claim 4, wherein the header field in the SIP response message from the 
service node is organized in a Backus-Naur format. 

7. The method of providing a VAS in a telecommunications network as 
set forth in claim 4, wherein the header field in the SIP register request from the SIPext 
SSP server is organized in a Backus-Naur form. 

8. The method of providing a VAS in a telecommunications network as 
set forth in claim 1 , wherein the return result comprises a destination routing number 
and the header field in the SIP response message from the service node includes a 
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connect operation, responsive to which the SlPext SSP server forwards the call 
initiated by the first user to the destination routing number. 

9. The method of providing a VAS in a telecommunications network as 
set forth in claim 1, wherein the return result comprises an error code, responsive to 
which the SIPext SSP server generates a SIP error message and forwards it to the first 
user. 

10. An integrated telecommunications network for providing a Value- 
Added Service (VAS), comprising: 

a SIPext SSP server including a proxy server and a service switching 
part, the proxy server for receiving a call initiation message from a first user with 
respect to a second user and the service switching part for determining if the second 
user has a subscription for the VAS; 

a trigger server containing user profiles associated with the VAS, the 
trigger server being activatable in response to a determination by the service switching 
part that the second user has a subscription to the VAS; 

means associated with the service switching part for formulating a 
register request based on user profile information for the second user, wherein the 
register request includes a header field containing an operation associated with the 
VAS; and 

a service node including an Intelligent Network Application Protocol 
(INAP)-compliant Service Logic Program (SLP) associated with the VAS and a SIPext 
SSP interface server for receiving and interpreting the register request from the service 
switching part, wherein the service node executes the SLP based on the contents of the 
header field in the register request received from the service switching part. 

1 1 . The integrated telecommunications network for providing a VAS as set 
forth in claim 10, wherein the proxy server has a first Internet Protocol (IP) address 
and the service switching part has a second EP address. 
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12. The integrated telecommunications network for providing a V AS as set 
forth in claim 10, wherein the register request contains linearized INAP-compliant 
parametric data associated with the operation. 

13. A system for providing a Value-Added Service (VAS) to a user in a 
telecommunications network operable with Session Initiation Protocol (SIP), the 
telecommunications network including a SIPext SSP server, a trigger server, and a 
service node having at least one Service Logic Program (SLP) associated with the 
VAS, wherein the SLP is operable with Intelligent Network Application Protocol 
(INAP), the system comprising: 

means for receiving a call initiation request with respect to the user; 

means for querying the trigger server, responsive to the determination 
that the user has a subscription for the VAS, to obtain a user profile associated with 
the user; 

means for formulating a SIP register request based on the user profile 
obtained from the trigger server, responsive to encountering an armed detection point 
in call processing, the register request including at least one header field, wherein the 
header field contains information specifying an operation that the service node is to 
perform with respect to the VAS, the header field further including call context data 
associated with the call initiation request with respect to the user; 

means for transmitting the register request to the service node; 

means for launching the SLP in the service node based on the operation 
specified in the header field and the call context data associated therewith; 

means for sending a SIP response message from the service node to the 
SIPext SSP server, the response message including a header field and a return result 
obtained in response to the launching of the SLP in the service node; and 

means for executing an action by the SIPext SSP server responsive to 
the header field and the return result in the response message received from the service 
node, the action being associated with the VAS. 



14. The system for providing a VAS to a user in a telecommunications 
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network as set forth in claim 13, further comprising means for transforming INAP- 
compliant data structures associated with the VAS into linearly sequenced parametric 
data forming a portion of the header field of the register request. 

15. The system for providing a VAS to a user in a telecommunications 
network as set forth in claim 14, wherein the return result comprises a destination 
routing number to which the call is to be forwarded. 
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FIG. 7 
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